Implementing changes for hardware, software, network and storage systems in large-scale electronic-business (e-Business) environments remains burdensome to customers. Rolling out changes, such as installing and uninstalling, upgrading or configuring systems can take weeks, partly because the complex interdependencies between applications and their supporting services are not made explicit. Therefore, human involvement and expertise is required.
Solving this change management problem automatically is advantageous in addressing the increasing complexity of computing systems. The number of relationships of a single computing resource (for example, a software component, a network component, a storage system) range from 10 to 100. The number of computing resource instance relationships in large-scale enterprise systems is often between 1,000,000 and 1,000,000,000. Given that a change to one or more computing resources may entail additional changes on a multitude of other computing resources, it is evident that minimizing the need for human involvement in the change management process would be advantageous.
Change management is a process that offers many automation challenges. The organizational frameworks behind existing change management processes tend to be ill-defined and highly variable in detail and formality. This makes it difficult to identify tasks for automation or to reuse standardized automation across environments within or between information technology (IT) organizations (for example, this is a particular problem for corporate mergers). Additionally, effective change management requires a great deal of accurate information on technical constraints, such as dependencies between IT services, the components that implement them, and the infrastructure supporting them. This information is rarely documented formally or kept up to date, therefore hindering change assessment and change impact prediction.
Existing approaches involving service providers and enterprise IT departments require setting up staging areas where changes are repeatedly tested to expose their potential impacts (and adjusted accordingly) before they can be safely deployed into production environments. Building staging environments is done manually in a step-by-step fashion and is documented in textual documents, termed ‘build sheets’ or ‘run books’ that are written in a natural language. Build sheets and run books are used to construct the production system, which is typically significantly larger than the staging system. This textual, human-readable representation, however, restricts the usage and execution of build sheets and run books to humans only. In particular, neither build sheets nor run books can be executed by an automated software deployment and provisioning system.
In addition, existing approaches, such as Integrated Development Environments (IDE), do not capture dependency information. Instead, existing approaches capture the containment hierarchy of a single individual software system that is being implemented without taking into account the existence of other software systems with which the software system under development needs to interact.
Existing approaches in the area of dependency management fall into 3 categories. The first category of approaches requires user input, that is, the manual entry of dependencies. An existing approach in this category is U.S. patent application Ser. No. 09/835,528 entitled “Method and Apparatus for identifying Software Components using Object Relationships and Object usages in Use Cases,” filed Apr. 17, 2001. This approach includes obtaining object dependency and object usages information from a user. Another existing approach in this first category is U.S. patent application Ser. No. 09/750,305 entitled “System and Method for managing Dependencies in a component-based System,” filed Dec. 29, 2000. This approach includes defining a resource that is part of an entity, recording a resource specifier for the resource, and recording resource dependency relationships definitions for the resource.
The second category of dependency management approaches requires access to the source code of all the components of an application in order to derive dependencies. An existing approach in this category is U.S. patent application Ser. No. 09/865,300 entitled “System and Method for the Manipulation of Software,” filed May 24, 2001. This approach includes analyzing a body of source code and deriving a set of components from the software architecture inherent in the body of source code. Another existing approach in this second category is U.S. patent application Ser. No. 09/839,644 entitled “Methods and Systems for identifying Dependencies between object-oriented Elements,” filed Apr. 20, 2001. This approach includes allowing a developer to simultaneously view a graphical and a textual display of source code.
The third category of dependency management approaches requires the presence of appropriate management instrumentation that surfaces dependency information. An existing approach in this category is U.S. patent application Ser. No. 10/055,426 entitled “Method and Apparatus for Distributed Systems Management,” filed Jan. 23, 2002. This approach includes providing a first agent monitoring a first managed device. Another existing approach in this third category is U.S. patent application Ser. No. 10/021,535 entitled “Methods and Apparatus for managing Components in an IT System,” filed Dec. 21, 2001. This approach includes discovery of components carried out using fingerprints of components, which can include key elements of the component that exist in a full model of all of the elements of the component.
Existing approaches in the area of software development include U.S. Pat. No. 4,751,635, which includes a host computer extracting information from each of the support system databases to obtain data indicative of development activity for various phases of the life cycle of the software system. Another existing approach in this area is U.S. Pat. No. 5,960,196, which includes a metric collector that provides a list of available metrics related to software development, tests, and loads building for the user's selection.
Existing approaches in the area of maintenance include U.S. Pat. No. 5,493,682, which includes assembling executable systems from defined component parts such as source code files and object code files.
Existing approaches in the area of software packaging include U.S. Pat. No. 5,835,777, which includes combining listed files, the needed resources, and any related installation materials.
Existing approaches in the area of electronic software distribution of whole program packages include U.S. Pat. No. 6,009,525, which includes software products being wrapped by their publishers in a straightforward, secure manner, but in such a way as to allow for the addition of information by downstream distribution channel partners, for example, distributors and merchants (resellers). Another existing approach in this area is U.S. Pat. No. 5,721,824, which includes installation of each dominant, or primary, package and installation of the dependent, or secondary, packages dependent on that dominant package.
Existing approaches in the area of updates and/or corrections and/or fixes and/or patches include U.S. Pat. No. 5,999,740, which includes accessing a remote file server to obtain a release file containing a list of software applications available from the remote server, and comparing the release file with the registration file to determine which of the installed applications have upgrades available. Another existing approach in this area is U.S. Pat. No. 5,805,891, which includes determining whether the software maintenance module requires test, and submitting the module to test if required.
Existing approaches in the area of determining conflicts in existing software and/or hardware configurations include U.S. Pat. No. 5,867,714, which includes communications circuitry that, from time to time, automatically transmits at least part of the current hardware and software configuration data of the computer system to a remote data source capable of identifying inherent conflicts in the hardware and software configuration.
The existing change management approaches rely on detailed static or design information, source code or management instrumentation.
It would thus be desirable to overcome these and other limitations in existing change management approaches.